Trucker Terminal System
- et adgangs kontrol system
Kravspecifikation
Udarbejdet af: Gruppe 7 (I2)
Medlemmer: Alex Hede 01065
Jacob
Germundsen 01011
Jeppe
Hasager 01048
Jesper
Johansen 02877
Søren
S Munk 02847
Vejleder: Michael E. Kristensen
|
Rev |
Dato |
Bemærkninger |
Side |
Afsnit |
|
01 |
14-03-2003 |
Første udgave |
- |
- |
|
02 |
28-03-2003 |
Rettede ”spærre
en bruger” til ”spærre et kort” |
|
3.2.2.7 |
|
02 |
28-03-2003 |
Tilføjede: ”Indtast
ønskede bruger nr.:” Resultatet af
fremkommer på listeform ”Indtast
kortnummer.:” |
|
4.1.2 |
|
03 |
04-04-2003 |
Tilføjede: ”Pc’en leveres
med fungerende 32-bit ODBC service.” |
|
2.8 |
Indholdsfortegnelse
2.3 Applikationens
begrænsninger
2.6 Krav
til udviklingsforløbet
5 Krav til applikationens
ydelse
1
Indledning
1.1
Formål
Der skal udvikles
et software system der muliggør kommunikation mellem pc og en
magnetkortterminal DV9802. Desuden skal softwaren forestå adgangskontroldelen
af det samlede system. Softwaren er samtidig svar på opgaven stillet i 2. semesterprojekt
på IHA IKT linien.
Produktets navn:
Trucker Terminal System (herfra kaldet TTS)
1.2 Referencer
Opgaveformuleringen,
se bilag 1.
Danvægt AS: Beskrivelse af kommunikationsprotokol i
DV9800 apparatserien, 1999, se bilag 2.
1.3 Læsevejledning
Kravspecifikationen
indeholder en generel beskrivelse af systemet samt applikationens funktion.
Dette efterfølges af de specifikke krav, hvor de enkelte krav er beskrevet i
detaljer til applikationens funktion.
Herefter
beskrives de eksterne grænsefladekrav, eksempelvis brugergrænseflade.
Til sidst
beskrives kvalitetsfaktorer og krav til applikationens ydelse.
1.4 Ordliste
I
kravspecifikationen er følgende udtryk anvendt:
Kunden: Vejleder
Michael E. Kristensen
Udgangstilstand: Det er den tilstand vores program
starter i.
Spærret tilstand: Det er en tilstand applikationen går
i hvis et kort er spærret.
Brugerprofiler: En brugerprofil er de data der er om en enkelt
bruger; pinkode, navn, kortnummer og kundenummer.
Terminal: Med
terminal menes DV9802.
PC: Her
menes en Pentium baseret computer med en RS422 port og Windows (NT/2000) eller
nyere.
2
Generel
beskrivelse
2.1 Systembeskrivelse
TTS består af 1
pc med Windows (NT/2000), skærm, keyboard, serielport, konsol applikation og
minimum 1 ekstern enhed kaldet DV9802.
Figur 1 Skematisk
tegning af adgangskontrolsystemet.
Brugeren indlæser
sit magnetkort og indtaster PIN-kode.
Applikationen
styrer informationen mellem terminalen og pc.
Terminalen
overfører ved forespørgsel kortnummer og den indtastede PIN-kode.
Ved accept af
kort og PIN-kode gives adgang.
Ved afvisning af
kort og PIN-kode nægtes adgang.
På pc’en kan der
oprettes, redigeres og slettes brugere.
Hver bruger
tildeles et kortnummer, en PIN-kode og et brugernummer, via et simpelt og
overskueligt menusystem.
2.2 Applikationens funktion
Applikationen der
afvikles på en pc, poller terminalen løbende, med fastlagte mellemrum. Når der
kommer svar tilbage fra terminalen, fortolkes svaret og applikationen vil validere
kort og pinkode. Er kortet gyldigt og pinkoden korrekt gives der adgang, ellers
nægtes der adgang. Indtastes en forkert PIN-kode, kan der prøves igen. Efter 3
forkerte indtastninger af PIN-kode spærres kortet.
2.3 Applikationens begrænsninger
Applikationen er
en konsolapplikation, der afvikles i et Windows miljø. Det vil i det her
tilfælde sige, at der ikke kan navigeres med mus. Alle kommandoer sker via
keyboard.
Applikationen kan
kun anvendes til at styre 1 terminal.
Der er ingen
kryptering under overførsel af data mellem applikationen og terminalen.
Applikationen kan
kun anvendes til DV9802.
2.4 Applikationens fremtid
Applikationen kan
i fremtiden udvides til at håndtere flere terminaler.
Applikationen kan
udvides med en grafisk brugerflade som giver mulighed for brug af mus.
Applikationen kan
udvides til at styre terminaler af andre modeller/fabrikater.
Applikationen kan
udvides til at håndtere andre protokoller.
2.5 Brugerprofil
Brugerne af
terminalen er lastbilchauffører. Det forventes at brugerne kan betjene en
magnetkortlæser, men der forventes ikke anden forudgående kendskab til edb.
Lastbilchaufførerne
forventes at bruge systemet ca. en gang dagligt.
Brugerne af
applikationen vil være kontor-personale. Det forventes at de har et
grundlæggende kendskab til computere og kan forstå dansk.
2.6 Krav til udviklingsforløbet
I
udviklingsforløbet anvendes ”Håndbog I Struktureret Program-Udvikling” 1.
udgave 10 oplag 2002.
Applikationen
bliver skrevet i programmeringssproget C++ til en Windows platform. Den vil
overholde den specificerede HDLC lignende protokol, se bilag 2.
Der udarbejdes
flowcharts som dokumentation for vores applikation med kildekoden som bilag.
Applikationen
skal kunne eksekveres på en Pentium-baseret pc under Windows (NT/2000) eller
nyere.
2.7 Omfang af kundeleverance
Kravspecifikation
Design-dokumentation
Implementering,
herunder en udskrift af sourcekode, samt kildekoden på en cd.
Test-dokumentation
Master
applikationen på en cd.
Brugermanual
2.8 Forudsætninger
Kunden leverer pc
og terminal.
Pc’en leveres med
fungerende 32-bit ODBC service.
3
De
specifikke krav
3.1 Definitioner
Pinkoden skal
bestå af 4 cifre fra 0-9.
Tolerancen på
alle tidsangivelser er på ± 1 sekund.
3.2 Funktionelle krav
3.2.1 Kortlæser og pinkode
3.2.1.1
Alt
udover de 4 første cifre ignoreres ved indtastning.
3.2.1.2
Første
gang kortet læses korrekt, skal processen fuldføres eller afbrydes, før en ny
proces kan starte.
3.2.1.3
Systemet
går i udgangstilstand, hvis der går 15 sekunder fra kortindlæsning til
afslutning af pinkode.
3.2.1.4
Systemet
går i spærret tilstand i 5 sekunder hvis kortet er spærret, hvorefter det går i
udgangstilstand.
3.2.1.5
Systemet
går i udgangstilstand hvis kortnummer er ukendt.
3.2.1.6
Der
skal holdes styr på hvor mange gange kortet er kørt igennem efterfulgt af
pinkode.
3.2.1.7
Ved 3
fejlslagne forsøg, spærres kortet.
3.2.1.8
Efter
korrekt indtastning af pinkode, har man igen 3 forsøg.
3.2.2 PC’en
3.2.2.1
Applikationen
bruger en database til opbevaring af brugerprofiler.
3.2.2.2
Applikationen
skal kunne indeholde minimum 100 brugere.
3.2.2.3
I
applikationen skal man kunne oprette en ny brugerprofil.
3.2.2.4
Applikationen
skal kunne søge i listen over brugere, udfra navn eller kundenummer.
3.2.2.5
Applikationen
skal kunne redigere en brugers navn, pinkode og kortnummer.
3.2.2.6
Applikationen
skal kunne fjerne en bruger.
3.2.2.7
Applikationen
skal kunne spærre et kort.
3.2.2.8
Er et
kort spærret i applikationen, skal det kunne åbnes igen.
3.2.2.9
Navnet
må højst være på 256 karakterer.
3.2.2.10
Kundenummer
må højst være 8 cifre.
3.2.2.11
Kortnummeret
skal være på 4 cifre.
3.2.2.12
Applikationen
skal kunne kontrollere i databasen om kortnummer og pinkode passer sammen.
3.2.3 Informationsdisplay
3.2.3.1
Før
indlæsning af kortet, vises teksten: ”Klar. Indlæs kort”.
3.2.3.2
Går
der mere end 15 sekunder fra kortindlæsning til afslutning af pinkode går
applikationen i udgangstilstand, med tilhørende displaytekst: ” Klar. Indlæs
kort”.
3.2.3.3
Efter
indlæsning af kort vises teksten: ”Indtast pinkode”.
3.2.3.4
Hvis
kortet er spærret vises teksten: ”Kortet er spærret” i 5 sekunder hvorefter
teksten ”Klar. Indlæs kort” vises.
3.2.3.5
Hvis
kortnummeret er ukendt vises teksten: ”Kortet er ukendt”.
3.2.3.6
Efter
indtastning af rigtig pinkode vises teksten: ”Godkendt”.
3.2.3.7
Efter
indtastning af forkert pinkode vises teksten: ”Pinkoden er forkert. Prøv igen”.
3.2.3.8
Efter
den 3. mislykkede indtastning vises teksten:” Forkert pinkode, kortet er
spærret” i 5 sekunder hvorefter teksten ”Klar. Indlæs kort” vises.
3.2.4 Tastatur
3.2.4.1
Funktionstasterne
har specifikke funktioner.
3.2.4.2
Funktionstasten
A afbryder forløbet, så man kan indlæse et nyt kort.
3.2.4.3
Funktionstasten
C sletter den indtastede pinkode.
3.2.4.4
Funktionstasten
E accepter den indtastede pinkode.
3.2.5 Numerisk display
3.2.5.1
Efter
endt indtastning af pinkode, kommer der 4 punktummer i det numeriske display.
3.2.6 Rød & Grøn lampe
3.2.6.1
Rød
lyser ved spærret kort.
3.2.6.2
Rød
lyser ved ukendt kort.
3.2.6.3
Rød
lyser hvis pinkoden er forkert indtastet 3 gange.
3.2.6.4
Grøn
lyser når pinkoden er accepteret.
4
Eksterne
grænseflade-krav
4.1 Bruger-grænseflade
4.1.1.1
Brugerfladen
er en dos konsol, hvor alle kommandoer sker med tastetryk efterfulgt af
[enter].
4.1.2 Ved redigering af brugerprofiler:
Hovedmenu er
opbygget som:
”(O)pret ny bruger. Betyder: tast
[O] for at oprette ny bruger.”
”(R)ediger bruger. Betyder: tast [R]
for at redigere en brugerprofil.”
”(F)jern bruger. Betyder: tast [F]
for at fjerne en bruger.”
”(S)pær bruger. Betyder: tast [S]
for at spærre en bruger.”
Figur 2. Eksempel på
skærmbillede af hovedmenu.
I det følgende beskrives undermenuerne, opret, rediger og slet bruger:
Opret ny bruger:
Der fremkommer følgende prompts på
skærmen:
”Tast (-1) for afbryd.”
”Indtast brugernavn.”
”Indtast brugerkortnummer.”
Er der allerede oprettet en bruger
med det indtastede kortnummer vises:
”Kortnummer XXXX er allerede
oprettet under Brugernavn.”
ellers
fremkommer der følgende prompt:
”Indtast pinkode.”
Efter indtastning af pinkode
fremkommer følgende prompt:
Bruger succesfuldt oprettet.
Rediger bruger:
Der fremkommer følgende prompt:
”Tast (-1) for afbryd.”
Søg på bruger:
Resultatet af søgningen kommer på
listeform på skærmen.
Under resultatlisten over brugere
fremkommer følgende prompt:
”Indtast ønskede bruger nr.:”
Resultatet fremkommer på listeform.
Følgende prompter fremkommer:
”Nuværende brugernavn: XXXXXXXXX
Rettes til: ”
”Indtast kortnummer.:”
”Nuværende kortnummer: XXXX Rettes
til: “
”Nuværende pinkode: XXXX Rettes til:
“
Fjern bruger:
Der fremkommer følgende prompt:
“Tast (-1) for afbryd.”
Søg på bruger:
Resultatet af søgningen kommer på
listeform på skærmen.
Under resultatlisten over brugere
fremkommer følgende prompt:
“Indtast ønskede bruger nr.”
“Bruger XXXXX er slettet.”
Spær bruger:
Der fremkommer følgende prompt:
“Tast (-1) for afbryd.”
Søg på bruger:
Resultatet af søgningen kommer på
listeform på skærmen.
Under resultatlisten over brugere
fremkommer følgende prompt:
“Indtast ønskede bruger nr.”
“Bruger XXXXX er spærret.”
4.1.3 Ved normal kørsel af kommunikation med DV9802:
På pc skærmen
vises følgende, der modtages fra DV9802, samt de handlinger applikationen
foretager:
“Kortnummer
modtaget.”
“Pinkode
modtaget.”
“Pinkode og
kortnummer tjekkes…”
“Pinkode og
kortnummer OK.”
4.2 Hardware-grænseflade
Grænsefladen
mellem pc og DV9802 er serielporten, der er sat op til at køre med en hastighed
på 9600 bps, 8 databit, 2 stopbit og lige paritet.
4.3 Software-grænseflade
Applikationen er
en DOS applikation og kan afvikles på en Windows baseret pc (Windows 2000/NT).
Til applikationen er knyttet en database.
4.4 Kommunikationsgrænseflade
Der anvendes en
HDLC lignende protokol, som er beskrevet i bilag 2.
5
Krav
til applikationens ydelse
Applikationen
skal:
fejlfrit
kommunikere med terminalen, på en 133 MHz pc med 64 MB ram eller mere.
fejlfrit
kommunikere med en database.
opdatere
databasen, umiddelbart efter hver behandling af nye data.
være kørende
inden for 15 sekunder efter start af applikationen
kunne køre uden
problemer efter en afbrydelse af pc’en.
6
Kvalitetsfaktorer
Kvalitetsfaktorerne
vurderes enkeltvis ud fra følgende 5-punkt skala. Faktorens værdi er anført i
parentes:
(1) Ukritisk
(2) Ikke særlig vigtig
(3) Vigtig
(4) Meget vigtig
(5) Særdeles vigtig
Pålideligheden
(5)
Oppetiden for
vores applikation er over 70%, under forudsætningen af at DV9802 fungerer
korrekt, strømforsyningen er stabil samt at pc-hardwaren, styresystemet og
andre softwareapplikationer fungerer korrekt.
Vedligeholdelsesvenlighed
(3)
Det kan først
fastslås senere i udviklingsforløbet, under implementeringen.
Udvidelsesvenlighed
(3)
Applikationen kan
udvides til at styre flere terminaler, håndtere flere brugere (truckere) og en
anden brugerflade.
Brugervenlighed
(3)
Det kan først
bestemmes senere, når applikationen er færdigudviklet.
Genbrugbarhed (2)
Hvis
applikationen udvides som beskrevet ovenfor, kan meget af applikationens kode
genbruges.
Integritet (5)
Systemet har høj
integritet, da overførslen af data fra terminal til pc har fejltjek.
Ved pc nedbrud
kan der forekomme korrupte filer, hvis der skrives til databasen samtidigt.
Integriteten bliver dermed lav.
7
Andre
krav
Der er i
øjeblikket ikke andre krav end de i afsnit 4 beskrevne krav.
Vor applikation
skal afvikles på en pc og en DV9802 stillet til rådighed af Ingeniørhøjskolen
Århus. Vi forventer at begge enheder er fuldt ud funktionsdygtige, da vort
program ellers ikke fungerer og ikke ville kunne testes op mod sluttesten.
8
Del-levering
Kravspecifikation,
design, implementering og test kan siges at være del-leveringer. Disse bliver
review’et, eventuelt omarbejdet, godkendt og afleveret til Michael E.
Kristensen, som projektet skrider frem.
Rapporten og
endeligt program afleveres den 6. juni kl. 11.00 til Michael E. Kristensen.
Der bliver ingen
del-levering af applikationen, rapporten og brugervejledningen.
9
Tidsplan
Nedenfor ses
tidsplanen for TTS projektet:
Tidsplanen er
baseret på den tidsplan der er på projektets hjemmeside.
http://studienet.e.iha.dk/klasser/i2a/prj2/pensumplan.htm
Punkterne er
opstillet efter SPU-modellen.
Nærmere detaljer
i Struktureret Program Udvikling s. 37.
Godkendt den / 2003
_________________________________________
Michael E.
Kristensen